feat: block time average#5504
Merged
Merged
Conversation
acud
reviewed
Jun 17, 2026
acud
reviewed
Jun 17, 2026
| if prev.number == 0 || newNumber <= prev.number { | ||
| return b.blockTime | ||
| } | ||
| if !newTime.After(prev.timestamp) { |
Contributor
There was a problem hiding this comment.
why not have this check also on the first if?
acud
approved these changes
Jun 17, 2026
gacevicljubisa
approved these changes
Jun 18, 2026
Member
There was a problem hiding this comment.
LGTM. Nice refinement and improvement on the anchor/extrapolation approach we discussed in #5394
martinconic
reviewed
Jun 18, 2026
| } | ||
|
|
||
| // computeAverageBlockTime returns the observed block time between prev and the | ||
| // freshly loaded header. Falls back to the configured block time only when prev |
Contributor
There was a problem hiding this comment.
I think comment is outdated because it also falls back when newNumber <= prev.number and when !newTime.After(prev.timestamp)
| blocks := newNumber - prev.number | ||
|
|
||
| averageBlockTime := elapsed / time.Duration(blocks) | ||
| if averageBlockTime > maxAverageBlockTime { |
Contributor
There was a problem hiding this comment.
Should we also have a lower bound as minAverageBlockTime, for maybe some misbehaving RPCs returning a large block jump with a near-equal timestamp ?
Contributor
Author
There was a problem hiding this comment.
I do not think it is actually possible...
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Checklist
Description
Added average block time for cache RPC call BlockNumber(). Average block time is computed as (newHeader.Time − prevAnchor.timestamp) / (newHeader.Number − prevAnchor.number) on each cache refresh, using consensus timestamps from the polled headers. If there is no previous anchor (prev.number == 0), or the block number or timestamp did not strictly increase, the configured default block time is used instead.
Observed intervals above maxAverageBlockTime (30 seconds) are capped, so a one-off long gap (chain stall) cannot inflate extrapolation for an extended period. It prevents case when chain got stuck and then cache used "stuck" block average for next N blocks (what can be hours).
Open API Spec Version Changes (if applicable)
Motivation and Context (Optional)
On-chain block time is not constant. When the node extrapolates block numbers using a fixed configured block time, the estimate drifts further from the real chain between RPC refreshes. This drift can be significant in redistribution game scenarios, where phase timing depends on accurate block numbers.
Related Issue (Optional)
#5485
Screenshots (if appropriate):
AI Disclosure